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ABSTRACT 



Packet processing logic includes a request queue for receiv- 
ing lookup requests from a packet processor, where each 
request includes information elements from a received 
packet and indicates that a route lookup and a packet 
classification are to be performed based on the information 
elements. Both a route lookup engine (RLE) and a packet 
classification engine (PCE) have respective inputs coupled 
to the request queue for receiving selected information 
elements from the requests. Based on the information ele- 
ments in each request, the RLE searches for forwarding 
information indicating how the packet corresponding to the 
request should be forwarded, and the PCE performs a 
classification process and generates classification informa- 
tion about the packet corresponding to the request. For each 
request, the forwarding information from the RLE and the 
classification information from the PCE are combined into a 
single result stored in a result queue. Each result is provided 
to the packet processor in a single communication transac- 
tion therewith. 

13 Claims, 8 Drawing Sheets 
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SUBMISSION AND RESPONSE 
ARCHITECTURE FOR ROUTE LOOKUP 
AND PACKET CLASSIFICATION REQUESTS 



CROSS REFERENCE TO RELATED 
APPLICATIONS 

None 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 

Not Applicable 

BACKGROUND OF THE INVENTION 

The present invention is related to the field of data 
communication networks. 

In data communication networks, network devices such as 
switches are used to route packets through the network. Each 
switch typically has a number of line interfaces, each 
connected to a different network segment. When a packet is 
received at a given line interface, forwarding logic deter- 
mines which line interface the packet should be transmitted 
from, and the packet is transferred to the appropriate out- 
going line interface to be sent toward its destination in the 
network. 

It is known to employ specialized forwarding logic in 
conjunction with a microprocessor on the line interface. The 
microprocessor is responsible for overall packet processing 
and forwarding. The forwarding logic stores one or more 
forwarding tables in high-speed memory. The forwarding 
tables contain information indicating how packets should be 
forwarded, typically based on a destination address con- 
tained within the packet. The forwarding tables are main- 
tained by a background process executing in the switch. 
When a packet is received at a line interface, the micropro- 
cessor generates a lookup request containing selected infor- 
mation from the packet, and issues the lookup request to the 
forwarding logic. The forwarding logic carries out a spe- 
cialized search of one or more forwarding tables, and returns 
a lookup result to the microprocessor. The lookup result 
contains an indication of whether forwarding information 
has been found, and if so then it contains the forwarding 
information itself. The microprocessor uses the forwarding 
information to forward the packet. This architecture is used 
to achieve packet forwarding rates greater than what is 
achievable using a microprocessor alone. 

It is also known to perform packet filtering in network 
devices such as switches. Packet filtering can be used to 
achieve various network management goals, such as traffic 
monitoring and security goals. Filtering criteria are estab- 
lished by network administrators, and provided to the 
switches or other devices that carry out the filtering opera- 
tion. Packets received by the switches are examined to 
determine whether their characteristics match the criteria for 
any of the established filters. For packets that satisfy the 
criteria for one or more filters, predetermined actions asso- 
ciated with those filters are carried out. For example, under 
certain circumstances it may be desirable that packets origi- 
nating from a given network node be discarded rather than 
being forwarded in the network. A filter can be defined in 
which the criterion is that a packet source address exactly 
match a specific value, which is the address of the node 
whose packets are to be discarded. The action associated 
with the filter is the discarding of the packet. When a packet 
is received whose source address satisfies this criterion, it is 
discarded rather than being forwarded in the normal fashion. 
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There are a number of different kinds of criteria that may 
be used to filter packets. These criteria include exact 
matches as well as range checking, i.e., checking whether a 
value in a packet falls in some range of values. Numerous 

5 packet parameters can be used as criteria, such as source 
address, destination address, port identifiers, type of service, 
and others. To be useful, packet filtering processes must 
allow filters to be flexibly defined using different combina- 
tions of these and other criteria. 

10 Because of this complexity inherent in packet filtering, it 
has traditionally been performed largely or exclusively in 
software within switches or other network devices support- 
ing packet filtering. Software-based filtering, however, pre- 
sents a bottleneck when high packet forwarding perfor- 

15 mance is required. Network administrators have had to make 
undesirable tradeoffs between network responsiveness and 
network security, for example, because previous systems 
have not been capable of robust packet filtering at line rates. 

20 BRIEF SUMMARY OF THE INVENTION 

In accordance with the present invention, packet process- 
ing logic in a network device is disclosed that provides 
high-speed forwarding searching along with packet classi- 

25 fication for packet filtering purposes. A novel request and 
response architecture is used between a packet-processing 
microprocessor and dedicated searching and classification 
logic to avoid communications bottlenecks that might oth- 
erwise reduce forwarding performance. 

30 The packet processing logic includes a request queue for 
receiving lookup requests from a packet processor, where 
each request includes various information elements from a 
received packet, and each request indicates that both a route 
lookup and a packet classification are to be performed based 

35 on the information elements contained in the request. A route 
lookup engine (RLE) has an input coupled to the request 
queue for receiving selected information elements from the 
requests. Similarly, a packet classification engine (PCE) has 
an input coupled to the request queue. Based on the infor- 

40 mation elements in each request, the RLE searches for 
forwarding information indicating how the packet corre- 
sponding to the request should be forwarded, and the PCE 
performs a classification process and generates classification 
information about the packet corresponding to the request. 

45 For each request, the forwarding information from the RLE 
and the classification information from the PCE are com- 
bined into a single result stored in a result queue. Each result 
is provided to the packet processor in a single communica- 
tion transaction therewith. 

50 This shared request and result architecture enhances the 
efficiency and speed of communication between the packet 
processor and the PCE and RLE, allowing for high-speed 
packet forwarding and classification. 

Other aspects, features, and advantages of the present 

55 invention are disclosed in the detailed description that 
follows. 

BRIEF DESCRIPTION OF THE SEVERAL 
VIEWS OF THE DRAWING 

60 

FIG. 1 is a block diagram of a network switch incorpo- 
rating a packet classification engine in accordance with the 
present invention; 

FIG. 2 is a block diagram of a line interface in the network 
65 switch of FIG. 1; 

FIG. 3 is a block diagram of a packet forwarding engine 
on the line interface of FIG. 2; 
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FIG. 4 is a block diagram of a packet header distributor 
application-specific integrated circuit (ASIC) in the for- 
warding engine of FIG. 3; 

FIG. 5 is a block diagram of a route and classification 
engine in the packet header distributor ASIC of FIG. 4; 5 

FIG. 6 is a diagram of the structure of a route and 
classification request passed to the route and classification 
engine of FIG. 5; 

FIG. 7 is a diagram of the structure of a route and Q 
classification result provided by the route and classification 
engine of FIG. 5; 

FIG. 8 is a diagram of the structure of a status indication 
provided by the route and classification engine of FIG. 5; 

FIG. 9 is a block diagram of a packet classification engine 15 
(PCE) in the route and classification engine of FIG. 5; and 

FIG. 10 is a block diagram of a route lookup engine (RLE) 
in the route and classification engine of FIG. 5. 

DETAILED DESCRIPTION OF THE 20 
INVENTION 

In FIG. 1, a network switch 10 is shown as including a 
number of line interfaces 12 connected to respective net- 
work segments 14. The line interfaces 12 are connected to a 
switch fabric 16 used to provide connections among the line 25 
interfaces 12 for packet forwarding. The overall operation of 
the switch 10, including the dynamic configuration of the 
switch fabric 16, is controlled by a switch control 18. In 
general, the various network segments 14 may be of differ- 
ent types. For example, certain of the network segments 14 30 
may be optical links operating at any of a variety of standard 
signalling rates, such as OC-3/STM-1 and OC-12/STM-4. 
Others of the network segments 14 may be non-optical links 
employing coaxial cable, for example, and carrying signals 
of different formats. 35 

Each line interface 12 is of course designed for operation 
with the specific type of network segment 14 to which it 
connects. The primary tasks of each line interface 12 are to 
transfer packets or frames received from an attached net- 4Q 
work segment 14 to another line interface 12 via the switch 
fabric 16 for forwarding on a network segment 14 attached 
to the other line interface 12, and to receive packets from the 
other line interfaces 12 via the switch fabric 16 for forward- 
ing on the attached network segment 14. ^ 

FIG. 2 shows the structure of one type of line interface 12. 
This interface contains four separate optical interface ports, 
each including physical input/output and framing circuitry 
20 and a forwarding engine 22. The forwarding engines 22 
are all connected to switch fabric interface logic 24, which 50 
interfaces with the switch fabric 16 of FIG. 1. The forward- 
ing engines also interface with a line interface I/O processor 
(IOP) 26. Timing control logic 28 and DC power circuitry 30 
are also included. 

Each forwarding engine 22 provides a bidirectional data 55 
path between a connected physical I/O block 20 and the 
switch fabric interface 24. Received packets are segmented 
into multiple fixed-size ATM-like cells for transfer through 
the switch fabric 16 of FIG. 1 to another line interface 12. 
Cells received from the switch fabric 16 via the switch fabric 60 
interface 24 are reassembled into packets for outgoing 
transfer to the connected physical I/O block 20. 

The IOP 26 is a general-purpose processor that performs 
background functions, i.e. functions that support the for- 
warding of packets that are not carried out on a per-packet 65 
basis. One function performed by the IOP 26 is receiving 
packet forwarding information and packet filtering informa- 



tion from the switch control 18 of FIG. 1, and distributing 
the information to the forwarding engines 22. This process 
is described below. 

FIG. 3 shows a block diagram of a forwarding engine 22. 
An inbound segmentation-and-reassembly (SAR) logic 
block 40 provides a data path from a physical I/O block 20 
to the switch fabric 16 of FIG. 2, and an outbound SAR logic 
block 42 provides a data path from the switch fabric 16 to 
the respective physical I/O block 20. Each SAR 40, 42 is 
coupled to a respective control memory 44, 46 and packet 
memory 48, 50 used in performing the segmentation or 
reassembly function. 

The SAR devices 40 and 42 are both connected to a 
packet header distributor (PHD) application-specific inte- 
grated circuit (ASIC) 52 via a 64-bit PCI bus 54. As 
described in more detail below, the PHD ASIC 52 provides 
FIFO queue interfaces between the PCI bus 54 and a 
separate 64-bit bus 56, The bus 56 connects the PHD ASIC 
52 with a forwarding processor (FP) 58 and forwarding 
processor memory 60. The PHD ASIC 52 is also connected 
to the IOP 26 of FIG. 2 by a separate bus 62. 

FIG. 4 shows the structure of the PHD 52 of FIG. 3. A set 
of receive queues or RX queues 64 is used for temporary 
buffering of packet headers and other messages bound for 
the FP 58. As shown, there are four RX queues 64, two 
queues for high-priority traffic and two queues for low- 
priority traffic. An example of high-priority traffic is traffic 
having a high Quality of Service (QOS) guarantee, such as 
a committed rate. Low-priority traffic is traffic having a 
lower QOS or no QOS guarantee, such as best -efforts. For 
each priority level, there is one queue (labeled "0") for traffic 
originating from the inbound SAR 40, and another queue 
(labeled "1") for traffic originating from the outbound SAR 
42. A set of transmit queues or TX queues 66 is used for 
temporary buffering of packet headers and other messages 
bound for the SARs 40, 42 from the FP 58. A route and 
classification engine 68 performs a route lookup and various 
packet filtering checks on behalf of the FP 58. The packet 
filtering operation is described below. The route and classi- 
fication engine 68 receives status information from the 
queues 64, 66 via signal lines 69, and makes this information 
available to the FP 58 in a manner described below. 

The overall operation of a forwarding engine 22 will be 
described with reference to FIG. 3 and FIG. 4. Packets are 
received by the inbound SAR 40 from the associated 
physical -layer circuitry 20 of FIG. 2, and are stored in the 
packet memory 48. The inbound SAR 40 transfers the 
packet headers to an appropriate one of the RX queues 64 in 
the PHD 52. The FP 58 polls the PHD 52 to determine queue 
status, and retrieves the packet headers from the RX queues 
64 as appropriate. As part of the header processing, the FP 
58 sends certain information elements from each header to 
the route and classification engine 68 in a route and classi- 
fication request. The route and classification engine 68 
performs a route lookup and various packet filtering checks 
against the header elements in the request, and places the 
results of these checks into a result queue (described below). 
The FP 58 obtains the route lookup and classification results 
from the result queue, and uses these results to create a new 
header for the packet. The new header is transferred back to 
the PHD 52 via one of the TX queues 66, along with 
information identifying the internal circuit on which the 
packet should be forwarded after segmentation. The inbound 
SAR 40 retrieves the new header, places it in the packet 
memory 48 with the payload portion of the received packet, 
segments the new packet and transfers the resulting cells to 
the switch fabric 16 of FIG. 1 on the internal circuit specified 
by the FP 58. 
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In the outbound direction, the outbound SAR 42 receives 
packets from the switch fabric 16 of FIG. 1, and reassembles 
these packets into the packet memory 50. Packet headers are 
sent to the PHD 52, and retrieved from the PHD 52 by the 
FP 58. For most packets, the route lookup and filtering 
checks will have already been performed during inbound 
processing, so these operations are not repeated. Some 
protocols, however, do require lookups and filtering for both 
inbound and outbound packets, and therefore these opera- 
tions are optionally performed by the FP 58 in conjunction 
with the route and classification engine 68. If appropriate, 
the FP 58 formulates a new header for the packet, based in 
part on the identity of the internal circuit on which the 
segmented outbound packet is received. This new header is 
written to the PHD 52, along with transmit circuit informa- 
tion. The PHD 52 transfers the new header to the outbound 
SAR 42. The outbound SAR 42 places the new header in the 
packet memory 50 along with the packet payload, and 
transmits the packet to the associated physical layer inter- 
face 20 of FIG. 2. 

FIG. 5 shows the structure of the route and classification 
engine 68. Requests from the FP 58 of FIG. 3 are placed into 
a single request queue 70, and results are returned in a single 
result queue 72. Each queue 70 and 72 holds up to 16 
request/result entries. A route lookup engine (RLE) 74 
performs route lookups, typically based on a destination 
address (DA) included in the header. A packet classification 
engine (PCE) 76 performs packet filtering checks, based on 
specified information included in the packet header. The 
operation of the PCE 76 is described in more detail below. 
Input FIFO buffers 78 are placed between the request queue 
70 and the RLE 74 and PCE 76, and output FIFO buffers 80 
are placed between the RLE 74 and PCE 76 and the result 
queue 72. The FIFOs 78 and 80 provide a measure of 
decoupling between the processing performed by the RLE 
74 and the processing performed by the PCE 76. A multi- 
plexer 81 enables the FP 58 to read either the result queue 
72, or status information including status from the request 
queue 70, the result queue 72, and the status appearing on 
the signal lines 69 of FIG. 4. The structure of these entries 
is described below. 

FIG. 6 shows the structure of the route and classification 
request that is passed to the PCE 76 and RLE 74 via the 
request queue 70 of FIG. 5. The size of the request is four 
64-bit words. The various fields are defined as follows: 



FIELD NAME 



DESCRIPTION 



Type RLE Entry type:0-Node, 1-Leaf 

Ind. RLE Indirect route: 

1 -Indirect, O-Direct 
Res. Unused reserved bit 

Order No. of DA bits to add to RLE pointer 

RLE Ptr. Base address of RLE entry to which DA 

is added (based on Order) 
PCE Root 0 Starting address for PCE rule 0 

PCE Root 1 Starting address for PCE rule 1 

0 Set to zero, used for alignment 

checking 

Req. ID Request identifier, copied to result to 

enable matching with request 
IP TOS The contents of the Type of Service 

(TOS) field of the received packet 
IP Protocol The contents of the Protocol field of 

the received packet 
TCP Flags The contents of the TCP Elags field of 

the received packet 
IP Source Address The IP Source Address of the received 



10 



15 



25 



30 



35 



-continued 


HELD NAME 


DESCRIPTION 




packet 


IP Dest Addr. 


The IP Destination Address of the . 




received packet 


TCP/UDP Source Port 


The identifier of the TCP/UDP port on 




which the packet was received 


TCP/UDP Dest. Port 


The identifier of the TCPAJDP port for 




which the received packet is destined 


Reserved 


Unused reserved bits 



As shown in the above table, there is a provision for two 
separate sets of classification checks, one beginning at an 
address labeled "PCE Root 0" and the other as "PCE Root 

r. 

The significance of these separate starting addresses is 
described below. 

As previously noted, the appropriate fields of the request 
are provided to the respective input FIFOs 78 for the RLE 
74 and PCE 76 of FIG. 5. Some of the fields, such as the 
Req. ID and the IP Dest. Addr., are provided to both the RLE 
74 and the PCE 76. Other fields are provided to only one or 
the other. The use of the fields routed to the PCE in particular 
is described below. 

FIG. 7 and FIG. 8 show the respective structures of the 
two different types of entries that are read from the route and 
classification engine 68 of FIG. 4. FIG. 7 shows a result 
entry, which is obtained from the result queue 72 of FIG. 5 
and conveys the result of a classification search. FIG. 8 
shows a status entry used to convey status information to the 
FP 58 of FIG. 3. 

The fields of the result entry shown in FIG. 7 are defined 
as follows: 



FIELD NAME 



DESCRIPTION 



50 



T 

Req. ID 
P 

I 

L 
E 
Z 

Rl-M 
Depth 

PCE Match Addr. 

RLE Flags 

RLE Next Hop Ptr. 



Type: 0 - PCE Result, 1 - PCE Status 

Request Identifier (from the request) 

PCE Match NOT Eound: 

0 = Match Found, 1 = Match NOT Found 

RLE Indirect Route: 

0 = Normal, 1 = Indirect 

RLE Long Search: 0 ■* Short, 1 «■ Long 

Error indicator: 0 = Normal, 1 = Error 

Zero padding 

Match in PCE Root 1 (valid only if P = 0) 
0 = Match in root 0, 1 » Match in root 1 
Depth of route lookup search 
Address of last rule checked in PCE 
Elags from RLE table entry 
Pointer from RLE table entry 



The fields of the status entry shown in FIG. 8 are defined 
55 as follows: 



FIELD NAME DESCRIPTION 



60 



Zero 

TX Message 
RCE Results 



RCE Requests 
Tx-0 



Unused, set to zero 

Remaining space in forwarding-processor-to- 
IQP message queue 

Number of pending entries in result queue 
72. Normally zero, because status inserted 
only when queue is empty. 
Number of empty entries in request queue 70 
Number of empty entries 
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associated with reading is reduced. Also, the FP 58 obtains 

-continued information about the queues around the RLE 74 and PCE 

" " 76, and about the RX queues 64 and TX queues 66, in a 

held name description single read transaction. 

I 5 FIG. 9 shows the structure of the PCE 76 of FIG. 5. Data 

Tx " 1 J in tx queues 66. representing filters and bindings (discussed below) are 

stored in a rule memory (RM) 82 and a criterion memory 

^TauLt to™ emrieS ' m ( CM > 84 * ^ CM 84 k dudcs three commonly addressed 

memories CMO 86, CM1 88 and CM2 90. Three comparison 

10 logic blocks 92, 94 and 96 are associated with respective 

ones of the criterion memories 86, 88 and 90. Addressing 

The general operation of the route and classification an d control logic 98 decodes requests received from the 

engine 68 will be described with reference to FIG. 5 through request queue 70 of FIG. 5, generates addresses for the RM 

FIG. 8. The FP 58 of FIG. 3 writes lookup and classification 82 and the CM 84, sequences through multiple rules as 

requests to the request queue 70. When a request reaches the 15 required by each request, and generates results that are 

front of the request queue 70, different information elements passed back to the result queue 72 of FIG. 5. The addressing 

from the request are written simultaneously into the respec- a nd control logic 98 also interfaces to the IOP 26 of FIG. 2 

tive input FIFOs 78 for the RLE 74 and the PCE 76, The t0 enable the reading and writing of the RM 82 and CM 84 

RLE 74 and PCE 76 operate on the separate pieces of each by the IOP 26. Bus transceivers 100 provide the necessary 

request independently, and in general finish their respective 20 data path between the IOP 26 and the RM 82 and CM 84. An 

processing operations for a given request at different times. AND gate 102 provides a single MATCH signal when 

The results of these operations are written to the output corresponding MATCHn outputs from the comparison logic 

FIFOs 80. When both sets of results for a given packet have blocks 92, 94 and 96 are all true. 

reached the front of the output FIFOs 80, a single combined R u i e se ts for packet filtering are typically originated by a 

result is written to the result queue 72. The combined results 25 Network Management Station (NMS), but can also be 

are read by the FP 58 and used to formulate new packet dynamically assigned by the FP 58 based on identified flows, 

headers and circuit information for the SARs 40 and 42 of Part or a n 0 f the following information is provided by the 

FIG. 3, as discussed above. nms or FP 58 for filters: IP Destination Address with mask; 

More particularly, the FP 68 uses the route and classifi- IP Source Address with mask; IP protocol identifier; TCP/ 

cation engine 68 in a batch fashion. When there is sufficient 30 UDP Source Port and Destination Port identifiers; IP Type of_ 

room in the request queue 70, a burst of requests are written. Service identifier and mask, and miscellaneous flags. The 

Respective portions of each request are handled by the PCE various information elements from a filter are compared 

76 and RLE 74, as previously mentioned. The FP obtains with corresponding elements from each received packet in 

results by issuing a read command to the RCE 68. For each order to determine whether the packet matches the filter 

read, a block of four 64-bit entries are returned to the FP 58 35 criteria. If so, some specific action for the filter is taken, such 

via the FP bus 56. Each block contains as many results from as intentionally discarding a packet. If not, some default 

the result queue 72 as are available at the time of the read, action is typically taken, such as allowing the packet to 

and a number of status entries as padding. Thus, one of five proceed toward its destination. 

different combinations of entries in a result block may be Traditionally, packet filters are represented as an ordered 

read: 40 list of comparison sets that are searched linearly. In the PCE 

1. 4 result entries 76, the filter elements are divided into criteria (the compari- 

2. 3 result entries followed by 1 status entry son values) and rules (the list itself and the operators to be 
„ „ . used tor each comparison). This separation of rules and 

3. 2 result entries followed by 2 status entnes {& m ^ ^ of separate ^ memory (RM) 

4. 1 result entry followed by 3 status entries 45 82 and criterion memory (CM) 84. The memories 82 and 84 

5. 4 status entries are separately optimized for their respective functions, thus 
The FP 58 will generally issue read commands until the enhancing efficiency and performance. Also, entries within 

result queue 72 is empty, which is inferred whenever one or the CM 84 can be referred to by multiple rules in the RM 82, 

more status entries are included in the result block. The FP further enhancing storage efficiency. 

58 then uses these results while the route and classification 50 The RM 82 contains an array of rule memory entries, each 

engine 68 processes the next batch of requests. The FP 58 of which may be one of two types. A first type contains a set 

uses the status information to manage the flow of requests, of operators and a pointer to a row of CM 84 that stores 

so that the RLE 74 and PCE 76 are kept busy and the queues comparands for a corresponding filter. A second type con- 

70 and 72 and FIFOs 78 and 80 are prevented from over- tains a pointer to another rule memory entry. These entries 

flowing. 55 are used to perform jumps between non-contiguous seg- 

It will be noted that in the illustrated embodiment, there ments in a set of rules being searched sequentially. In the 

is only one status entry that can be read, and the multiple illustrated embodiment, the RM 82 can contain up to 16 K 

status entries in a result block represent multiple reads of this entries. 

single entry. In alternative embodiments it may be useful to The CM 84 is segmented into three separate memories 

provide additional, lower-priority information in the second 60 CMO 86, CM1 88 and CM2 90, each of which can contain 

through fourth status entries, for example for statistics up to 4 K entries in the illustrated embodiment. The orga- 

gathering purposes or other background processing. nization of the CM 84 exploits a hierarchy that is inherent in 

One significant advantage of appending status informa- IP packet classification. Because filtering on certain fields is 

tion to results is improved efficiency in using the FP bus 56. usually accompanied by filtering based on other fields as 

Whenever the FP 58 issues a read for results, either useful 65 well, it is reasonable to restrict which fields are stored, in the 

results or useful status information is returned. Additionally, separate memories CMO, CM1, and CM2. These restrictions 

the result block is returned in burst fashion, so that overhead further enhance storage efficiency. The most commonly 
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filtered fields, Source Address and Destination Address, are 
supported in all three memories CMO 86, CM1 88 and CM2 
90. As described below, other fields are supported only in 
CM1 88 and/or CM2 90. This architecture maximizes the 
flexibility with which space in the CM 84 can be allocated, 5 
while at the same time enabling powerful parallel searches. 
The structure and use of CM 84 are described in more detail 
below. 

The operation of the packet classification engine (PCE) 76 
proceeds generally as follows: 10 

1. The RM 82 and the CM 84 are initialized by the IOP 26 
of FIG. 2. This happens at power-up, and during operation 
either by dynamic assignment or by a Network Manage- 
ment Station (NMS) (discussed below). 

2. A packet classification request submitted by the FP 58 is 15 
retrieved from the request queue 70 of FIG. 5. 

3. The RM 82 is indexed by the contents of the root 0 address 
of the request to retrieve the first rule memory entry of the 
search. If the entry is a pointer type, then this step is 
repeated for the rule memory address in the retrieved 20 
entry. It is possible for this step to repeat multiple times. 

4. If the retrieved rule memory entry is an operator type, then 
a criterion memory entry is retrieved at the location 
specified by the CM address in the rule memory entry. 
Selected comparands from the CM 84 are compared with 25 
corresponding fields of the request, according to the 
operator in the rule memory entry. Various fields may be 
masked as described above. 

5. The rule memory address increments by one until either 

an entry having a DONE bit set to one is reached, or a 30 
match condition is found (i.e. the result of the comparison 
operation is TRUE). A rule may have its CARRY bit set, 
which requires that the next rule also evaluate as TRUE 
before a match is declared. 

6. If any rule memory entry encountered in the search is a 35 
pointer type of entry, it points to another rule memory 
entry rather than to a criterion memory entry. In this case, 
sequential rule evaluation continues beginning at the 
pointed-to rule memory entry. 

7. The above process is performed once beginning at the root 40 
0 address in the request. If DONE is reached for the filters 
associated with root 0, then the process is repeated 
beginning at the root 1 address. When a match is found, 
the result indicates whether it has been found using root 

0 or root 1 rules. 45 

8. When the search terminates, either by encountering a 
match or by encountering DONE in the root 1 search, a 
result is written back to the result queue 72 indicating the 
results of the filtering check. The result contains the 
address of the last rule checked, and whether or not a 50 
match has been found. If a match has been found, the 
address is used by the FP 58 to index into an action table, 
which initiates an action appropriate to the result. For 
example, if the match is for a rule indicating that all 
packets having a DA of less than a certain value should be 55 
dropped, then the action table points to a routine that 
causes the packet to be intentionally discarded. 

FIG. 10 shows the structure of the route lookup engine 
(RLE) 74 of FIG. 5. A memory 110 is used to store 
forwarding tables provided by the IOP 26 of FIG. 2. Lookup 60 
control logic 112 controls the operation of the memory 110, 
and contains interfaces to the IOP 26, the RLE input FIFO 
78 of FIG. 5, and the RLE output FIFO 80 of FIG. 5, 

The RLE 74 is a hardware search engine used to deter- 
mine a next-hop index for the forwarding processor 58 of 65 
FIG. 3. The RLE performs both unicast and multicast IP 
address lookups on IP networks, for example Virtual private 
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Networks (VPNs) and the public Internet. Each IP network 
is assigned a root of a forwarding table in the memory 110 
that is specific to that network. 

Searching is performed first on the IP destination address 
(DA), and subsequently on the IP source address (SA) if the 
packet is multicast. This operation takes place automatically, 
and normally terminates when a next hop index is found, or 
the end of the search key (DA or SA) is reached without an 
index having been found. Various lookup algorithms may be 
used, including so-called Patricia tree algorithms. As shown 
in the description of the result above, a successful search 
returns a next hop pointer found in the forwarding table at 
a location corresponding to the search key (either DA or 
SA). The next hop pointer is a pointer into a pre-defined 
table of network addresses available to the forwarding 
processor 58 for creating forwarding envelopes for mes- 
sages. 

A submission and response architecture for packet route 
lookup and classification requests has been described. It will 
be apparent to those skilled in the art that other modifications 
to and variations of the above-described technique are 
possible without departing from the inventive concepts 
disclosed herein. Accordingly, the invention should be 
viewed as limited solely by the scope and spirit of the 
appended claims. 

What is claimed is: 

1. Packet processing apparatus, comprising: 

a request queue operative to receive lookup requests from 
a packet processor, each request including various 
information elements from a corresponding received 
packet and indicating that both a route lookup and a 
packet classification are to be performed based on the 
information elements contained in the request, the 
request queue having associated status information 
operative to indicate the number of empty entries 
therein; 

a route lookup engine (RLE) having an RLE input queue 
and an RLE output queue, the RLE input queue being 
coupled to the request queue and being operative to 
receive selected information elements of requests from 
the request queue, the RLE being operative based on 
the selected information elements of each request to 
search for forwarding information indicating how the 
packet corresponding to the request should be 
forwarded, the RLE being operative to place the for- 
warding information into the RLE output queue upon 
completion of the search; 

a packet classification engine (PCE) having a PCE input 
queue and a PCE output queue, the PCE input queue 
being coupled to the request queue and being operative 
to receive selected information elements of requests 
from the request queue, the PCE being operative based 
on the selected information elements of each request to 
perform a classification process and to generate clas- 
sification information about the packet corresponding 
to the request, the PCE being operative to place the 
classification information into the PCE output queue 
upon completion of the classification process; and 

a result queue coupled to the RLE output queue and the 
PCE output queue, the result queue being operative to 
(i) receive the forwarding information and the classi- 
fication information resulting from each request, (i) 
include the received forwarding information and clas- 
sification information in a single result for each request, 
and (iii) provide each result to the packet processor in 
a corresponding communication transaction therewith. 

2. Packet processing apparatus according to claim 1, 
wherein the PCE contains a rule memory including rule 
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memory entries, each rule memory entry representing cor- 
responding classification criteria applied in the classification 
process, and wherein the classification information included 
in each result includes an address of a rule memory entry 
whose corresponding classification criteria are satisfied by 5 
the request for which the result has been created. 

3. Packet processing apparatus according to claim 1, 
wherein the set of information elements used by the PCE and 
the set of information elements used by the RLE overlap but 
are not identical. 10 

4. Packet processing apparatus according to claim 3, 
wherein the overlapping information elements include a 
destination address from received packets. 

5. Packet processing apparatus, comprising: 

a request queue operative to receive lookup requests from 35 
a packet processor, each request including various 
information elements from a corresponding received 
packet and indicating that both a route lookup and a 
packet classification are to be performed based on the 
information elements contained in the request, the 20 
request queue having an associated status information 
for indicating the number of empty entries therein; 

a route lookup engine (RLE) having an RLE input queue 
and an RLE output queue, the RLE input queue being 
coupled to the request queue and being operative to 25 
receive selected information elements of requests from 
the request queue, the RLE being operative based on 
the selected information elements of each request to 
search for forwarding information indicating how the 
packet corresponding to the request should be 30 
forwarded, the RLE being operative to place the for- 
warding information into the RLE output queue upon 
completion of the search; 

a packet classification engine (PCE) having a PCE input 35 
queue and a PCE output queue, the PCE input queue 
being coupled to the request queue and being operative 
to receive selected information elements of requests 
from the request queue, the PCE being operative based 
on the selected information elements of each request to 4Q 
perform a classification process and to generate clas- 
sification information about the packet corresponding 
to the request, the PCE being operative to place the 
classification information into the PCE output queue 
upon completion of the classification process; 45 

a result queue coupled to the RLE output queue and the 
PCE output queue, the result queue being operative to 
(i) receive the forwarding information and the classi- 
fication information resulting from each request, (ii) 
include the received forwarding information and clas- 50 
sification information in a single result for each request, 
and (iii) provide each result to the packet processor in 
a corresponding communication transaction therewith, 
the result queue having an associated status information 
for indicating the number of empty entries therein; and 55 

a read logic, the read logic being operative to create a 
combined result and to provide the combined result to 
the packet processor as part of a single corresponding 
communication transaction therewith, wherein the 
combined result is created by combining a result from 60 
the result queue with the status information associated 
with the request queue and the result queue. 

6. Packet processing apparatus according to claim 5, 
wherein the read logic is coupled to the packet processor via 

a bus, and wherein the combined result is provided to the 65 
packet processor as a multi-word block over multiple suc- 
cessive bus cycles. 
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7. Packet processing apparatus according to claim 6, 
wherein the combined result is a fixed size block including 
as many result entries as are available in the result queue at 
the time the result block is provided to the packet processor, 
and as many status entries as are necessary to pad the result 
block to its fixed size. 

8. Packet processing apparatus according to claim 5, 
wherein the read logic is coupled to the packet processor via 
a bus, and further comprising additional queues also coupled 
to the packet processor via the bus, each additional queue 
having associated status information indicating the number 
of empty entries therein, and wherein the status information 
of the additional queues is also included in the combined 
result. 

9. Packet processing apparatus according to claim 1, 
wherein the result queue having an associated status infor- 
mation operable to indicate the number of empty entries 
therein. 

10. Packet processing apparatus according to claim 9, 
further comprising a read logic, the read logic being opera- 
tive to create a combined result and to provide the combined 
result to the packet processor as part of a single correspond- 
ing communication transaction therewith, wherein the com- 
bined result is created by combining the status information 
of the result queue with a result from the result queue. 

11. Packet processing apparatus according to claim 9, 
further comprising a read logic, the read logic being opera- 
tive to create a combined result and to provide the combined 
result to the packet processor as part of a single correspond- 
ing communication transaction therewith, wherein the com- 
bined result is created by combining a result from the result 
queue with the status information of the result queue and the 
request queue. 

12. Packet processing apparatus, comprising: 

a request queue operative to receive lookup requests from 
a packet processor, each request including various 
information elements from a corresponding received 
packet and indicating that both a route lookup and a 
packet classification are to be performed based on the 
information elements contained in the request, the 
request queue having a request queue associated status 
information for indicating the number of empty entries 
therein; 

a route lookup engine (RLE) having an RLE input queue 
and an RLE output queue, the RLE input queue being 
coupled to the request queue and being operative to 
receive selected information elements of requests from 
the request queue, the RLE being operative based on 
the selected information elements of each request to 
search for forwarding information indicating how the 
packet corresponding to the request should be 
forwarded, the RLE being operative to place the for- 
warding information into the RLE output queue upon 
completion of the search; 

a packet classification engine (PCE) having a PCE input 
queue and a PCE output queue, the PCE input queue 
being coupled to the request queue and being operative 
to receive selected information elements of requests 
from the request queue, the PCE being operative based 
on the selected information elements of each request to 
perform a classification process and to generate clas- 
sification information about the packet corresponding 
to the request, the PCE being operative to place the 
classification information into the PCE output queue 
upon completion of the classification process; 

a result queue coupled to the RLE output queue and the 
PCE output queue, the result queue being operative to 
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(i) receive the forwarding information and the classi- 
fication information resulting from each request, (ii) 
include the received forwarding information and clas- 
sification information in a single result for each request, 
and (iii) provide each result to the packet processor in 5 
a corresponding communication transaction therewith, 
the result queue having a result queue associated status 
information for indicating the number of empty entries 
therein; and 

a read logic, the read logic being coupled to the packet 10 
processor via a bus, operative to create a combined 
result and to provide the combined result to the packet 
processor as a multi-word block over multiple succes- 
sive bus cycles, wherein the combined result is created 
by combining a result from the result queue and the 15 
status information associated with the request queue 
and the result queue. 
13. Packet processing apparatus, comprising: 
a request queue operative to receive lookup requests from 
a packet processor, each request including various 20 
information elements from a corresponding received 
packet and indicating that both a route lookup and a 
packet classification are to be performed based on the 
information elements contained in the request, the 
request queue having a request queue associated status 25 
information for indicating the number of empty entries 
therein; 

a route lookup engine (RLE) having an RLE input queue 
and an RLE output queue, the RLE input queue being 3Q 
coupled to the request queue and being operative to 
receive selected information elements of requests from 
the request queue, the RLE being operative based on 
the selected information elements of each request to 
search for forwarding information indicating how the 35 
packet corresponding to the request should be 
forwarded, the RLE being operative to place the for- 
warding information into the RLE output queue upon 
completion of the search; 
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a packet classification engine (PCE) having a PCE input 
queue and a PCE output queue, the PCE input queue 
being coupled to the request queue and being operative 
to receive selected information elements of requests 
from the request queue, the PCE being operative based 
on the selected information elements of each request to 
perform a classification process and to generate clas- 
sification information about the packet corresponding 
to the request, the PCE being operative to place the 
classification information into the PCE output queue 
upon completion of the classification process; 

a result queue coupled to the RLE output queue and the 
PCE output queue, the result queue being operative to 
(i) receive the forwarding information and the classi- 
fication information resulting from each request, (ii) 
include the received forwarding information and clas- 
sification information in a single result for each request, 
and (iii) provide each result to the packet processor in 
a corresponding communication transaction therewith, 
the result queue having a result queue associated status 
information for indicating the number of empty entries 
therein; and 

a read logic, the read logic being coupled to the packet 
processor via a bus, operative to create a combined 
result and to provide the combined result to the packet 
processor as part of a single corresponding communi- 
cation transaction therewith; and 

a plurality of additional queues coupled to the packet 
processor via the bus, each of the plurality of additional 
queues having associated status information indicating 
the number of empty entries therein, wherein the com- 
bined result is created by combining a result from the 
result queue with the status information of the plurality 
of additional queues, the request queues, and the result 
queue. 

***** 
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